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A USERS  GUIDE  FOR  THE  (A)DVANCEl)  (SCIENTIFIC  (OOMPUTER 


I.  Introduction 

The  purpose  of  this  user’s  guide  is  to  acquaint  both  the  beginning  user  and  the  advanced 
user  with  information  that  is  not  readily  available  from  other  sources  concerning  operations  of 
the  ASC  computer.  It  is  not  intended  to  replace  any  of  the  Texas  Instruments  Software  manu- 
als nor  to  represent  itself  as  being  a complete  guide  It  will,  however,  provide  pointers  to 
places  where  more  information  can  be  obtained. 

As  can  be  seen  from  the  table  of  contents,  the  subject  separates  into  several  distinct  cata- 
gories.  The  first  try  at  using  this  computer  might  well  be  to  use  Chapter  VI  and  submit  a job. 
Once  the  initial  shock  of  actually  having  output  returned  is  over,  one  can  proceed  with  the 
problem  of  utilizing  the  facilities  that  are  available. 

The  ASC  computer  (manufactured  by  Texas  Instruments)  is  a general  purpose  vector 
computer  with  the  additional  feature  that  instructions  are  processed  in  a pipe-line  mode.  This 
simply  means  that  the  box  that  does  the  actual  work  is  looking  at  more  than  one  instruction.  In 
fact,  it  can  be  working  on  as  many  as  four  instructions  simultaneously,  and,  unless  a branch 
causes  some  instructions  to  be  discarded,  produces  one  result  each  machine  cycle.  Since  the 
NRL  version  has  two  arithmetic  units,  the  computer  can  be  processing  up  to  eight  instructions 
at  one  time.  Such  an  architecture  enables  the  hardware  to  make  the  most  efficient  use  of  the 
cables  that  connect  the  various  parts  of  the  computer  If  processing  were  not  done  in  this 
manner,  then  the  computer  would  stand  idle  part  of  the  time,  namely  that  part  of  the  time 
when  it  is  having  to  fetch  operands  after  it  has  interpreted  an  instruction.  As  it  can  operate, 
however,  by  the  time  the  arithmetic  unit  is  ready  to  execute  a particular  instruction,  the  data  is 
already  available 

The  vector  nature  of  the  computer  is  simply  the  ability  of  the  arithmetic  unit  to  intrepret 
only  one  instruction  and  perform  this  operation  on  a large  set  of  data  This  makes  for  more 
efficient  utilization  in  that  fewer  machines  cycles  need  to  be  devoted  to  interpreting  instruc- 
tions. and  more  can  be  spent  doing  computations. 
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II.  Libraries 


There  are  primarily  two  types  of  libraries.  They  are  the  program  library  and  the  macro  li- 
brary. Program  libraries  can  be  source,  object  or  load  module  (run  time)  libraries.  The  most 
common  of  these  are  source  and  object  module  libraries.  Load  module  libraries  will  not  be 
dealt  with  extensively  in  this  guide. 

The  following  two  sections  (II. A and  II. B)  deal  with  and  explain  these  two  types  of  li- 
braries in  some  detail  as  well  as  giving  a brief  description  of  macro  libraries.  The  actual  struc- 
ture that  is  used  by  the  operating  system  that  handles  the  libraries  will  not  be  discussed  since  it 
is  not  important  in  using  these  facilities.  What  is  important,  however,  is  to  understand  what 
the  libraries  can  contain,  so  that  maximum  use  can  be  made  of  them. 

Disk  and  tape  files,  in  general,  come  in  three  flavors,  namely  sequential  (PS),  partitioned 
(PDS),  and  direct  secondary  (core  image)  files  (DS).  Sequential  (physical  sequential  or  PS) 
files  are  equivalent  to  having  the  program  (set  of  cards)  in  one  long  tray.  Partitioned  (parti- 
tioned direct  secondary  or  PDS  ) files  are  similar  to  having  a library  of  books  where  one  must 
refer  to  the  card  catalog  first  in  order  to  find  the  location  of  the  book.  This  latter  structure  al- 
lows one  to  work  on  individual  programs  (books)  without  having  to  keep  track  of  all  other  pro- 
grams. An  analogy  might  be  the  individual  books  in  an  encyclopedia;  it  is  much  easier  to 
change  one  book  and  reprint  it  if  an  error  is  found  than  would  be  the  case  if  the  whole  lot  were 
bound  together  whence  the  entire  encyclopedia  would  have  to  be  reprinted  each  time  an  error 
were  found.  Experience  has  shown  that  errors  often  arise  when  these  file  types  are  confused. 
Direct  secondary  (DS)  files  will  not  be  dealt  with  in  this  guide,  since  typical  users  seldom  have 
need  to  manipulate  them  directly. 

Physical  sequential  files  contain  only  one  module,  whereas  partitioned  files,  by  their  very 
nature,  contain  one  or  more  modules  with  a concomitant  directory.  Discussion  of  sequential 
files  can  be  found  in  the  "Sequential  I/O  User’s  Guide"  (#930055)  and  information  on  PDS 
files  can  be  obtained  from  the  manual  "Partitioned  Direct  Secondary  Files"  (#931487). 

In  general,  program  files  should  be  maintained  in  the  PDS  format  to  facilitate  updating 
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programs.  In  some  specialized  cases,  however,  physical  sequential  files  are  used.  When  pro- 
gram files  are  organized  in  the  PS  format,  they  are  referred  to  simply  as  files  or  modules. 
When  they  are  organized  according  to  the  PDS  format,  then  the  program  element  is  called  a 
module  and  is  a member  of  the  library. 
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II. A.  Program  Libraries 

Program  libraries  contain  three  types  of  programs,  that  is,  programs  in  three  forms. 
These  are  source,  object  and  load  module  libraries.  Source  and  object  files  can  be  organized  in 
either  of  the  first  two  forms  of  disk  files  (PS  or  PDS),  whereas  load  modules  must  be  organized 
in  the  direct  secondary  or  DS  format. 


Source  modules  are  card  image  format  and  there  are  two  principle  editors  to  deal  with 
these:  CIFER  (#930032)  and  SMS  (#931485).  CIFER  [Card  Image  File  EditoR]  is  the  more 
commonly  used  of  the  two  editors  and  is  quite  simple  in  its  use.  But  it  leaves  the  entire  card 
image  on  the  disk  file  and  thus  the  space  used  for  blanks  is  wasted.  SMS  on  the  other  hand 
compacts  files  and  in  addition  allows  for  systematic  updating,  but  is  much  more  difficult  to  learn 
initially  becaue  of  the  lack  of  examples.  A few  examples  of  the  use  of  CIFER  and  SMS  will  be 
given  in  the  chapter  on  examples  (VI  and  VII).  Source  modules,  in  general  are  just  like  card 
decks.  Any  information  that  can  be  contained  in  a card  deck  can  be  contained  in  a source  pro- 
gram module,  including  Job  Specification  Language  cards  The  principle  use  of  source 
modules,  however,  is  to  contain  the  source  for  a program.  A source  module  can  be  changed  by 
use  of  an  editor  and  recompiled  or  submitted  directly  for  use  as  a job,  depending  on  the  mode 
in  which  one  is  operating 

Object  modules  contain  only  the  output  from  language  translators.  The  language  transla- 
tors translate  source  code  into  machine  language  code  The  specific  form  of  an  object  module 
is  not  important,  but  it  can  be  found  in  the  linkage  editor  manual  (#930057).  Object  modules 
can  be  saved  when  the  source  is  not  to  be  changed  from  one  run  to  the  next  and  the  user  does 
not  wish  to  spend  money  recompiling  the  program  These  modules  (elements  of  the  library) 


are  used  only  by  the  linkage  editor  to  create  a program  which  can  be  excuted  directly  on  the 
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ASC.  The  module  is  stored  in  card  image  format,  and  is  directly  comparable  (and  compatible) 
with  a similar  card  deck  Input  to  the  linkage  editor  can  be  from  disk,  tape  or  cards.  These 
modules  are  not  excutable  directly,  but  rather,  they  must  be  linked,  that  is,  all  external  refer- 
ences must  be  found  prior  to  execution  An  example  of  an  external  reference  would  be  refer- 
ence to  another  subroutine  or  to  the  Fortran  Input  Output  routines. 

II. B.  Macro  Libraries 

Macro  libraries  contain  macros.  Macros  are  simply  sets  of  JSl.  (see  Section  IV)  which  are 
used  repeatedly,  and  with  few,  if  any,  changes  from  execution  to  execution.  Examples  of  mac- 
ros are  MFTN,  MLNK  and  MEXQT  If  one  examines  the  expansion  (in  the  JSL  summary  of  a 
job)  of  a macro,  one  will  see  that  a given  line  (or  card)  can  produce  many  lines  of  JSL.  The 
detailed,  expanded,  JSL  includes  Operating  System  directives  which  are  environment  dependent 
and  usually  do  not  concern  the  user  directly  (as  always,  there  are  exceptions  to  this  rule).  For 
example,  Load  Time  Parameters  for  the  NX  compiler  (FORTRAN  language  translator)  are 
specified  in  this  manner,  it  is  more  flexible  to  have  such  a capability  and  implement  the  en- 
vironmental specifications  (what  machine,  operating  system,  etc  ),  by  macros  rather  than  build- 
ing the  specifications  into  each  program 

Macro  libraries  are  similar  to  the  PDS  program  libraries  in  that  they  too  have  a directory 
to  keep  track  of  the  various  modules  T he  most  important  difference  is  in  accessing  these  li- 
braries. For  macros,  one  must  use  the 

/ MAC  ASCi  

rather  than  the  usual 
/ ASCi 

command  (read  the  next  two  sections  on  JSL.  to  understand  the  difference).  For  details  on  the 
system  macros,  that  is,  the  defaults  and  details  of  what  they  do,  see  "JSL  System  Macros" 
manual  (#9300.14),  and  the  R C C.  computer  notes  #105  and  #137 
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Macros  are  accessed  by  the  JSL  translator  (see  Section  IV  & V)  in  a fashion  similar  to 
that  used  by  language  editors  (C1FER,  SMS,  etc.)  to  find  programs  in  PDS  libraries.  When  the 
translator  encounters  a JSL  name,  the  macro  name  list  is  searched  to  determine  if  the  name 
refers  to  a macro.  The  list  is  set  up  (or  modified)  when  a MACASG  verb  is  encountered.  This 
list  of  macro  names  can  be  changed  (this  feature  is  useful  mostly  for  interactive  users)  by 
releasing  the  macro  file  together  with  the  file  SYS.JSLM. 

Examples  of  macros  and  their  use  will  be  given  in  the  section  on  examples  (VI  and  VII) 
and  a more  detailed  explanation  is  given  in  Appendix  I. 

III.  Catalog  Structure  - Where  Are  Your  Programs 

The  catalog  system  is  simply  a means  for  the  computer  to  store  your  programs  and 
remember  where  they  are  located.  The  operating  system  is  designed  so  that  the  use  of  the  cata- 
log is  device  independent.  It  works  quite  well  except  for  one  minor  problem  in  using  tape  files 
in  which  case  disk  space  must  be  allocated  for  the  tape  staging  - see  the  section  on  examples. 
The  difference  between  disk  and  tape  files  is  mostly  locally  imposed  (different  charge  rates)  ex- 
cept that  to  an  interactive  user,  a tape  mount  is  noticeably  slower  than  a disk  access.  With  the 
catalog  structure  as  simple  as  it  is,  there  is  little  need  to  use  large  card  decks  to  run  jobs.  Pro- 
grams are  more  properly  stored  on  disk  or  tape,  and  accessed  via  the  catalog  structure. 

The  terminology  of  the  catalog  structure  format  is  straight-forward.  A root  node  is  the 
first  node  Useis  cannot  change  this.  Examples  of  root  nodes  are  SSSYSCAT,  USERCAT  and 
AFFIL.  One  creates  nodes,  and  a path  connects  the  root  node  to  the  node  of  interest.  The 
names  themselves  are  called  edgenames.  Generally  users  start  working  with  the  forth  node.  As 
an  example, 

USERCAT/D77/L50/MACROS 

represents  a path  with  nodes  at  USERCAT,  D77,  L50  and  MACROS.  D77  is  a son  of  the  root 
node  USERCAT  and  is  the  father  of  L50,  etc. 
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A node  by  itself  contains  nothing.  One  must  create  VERSIONS  at  a node.  This  is  the 
substance  of  the  catalog  structure.  Program  files,  etc.,  are  versions  at  a node.  Versions  can  be 
on  disk  [head  per  track  (HPT)  or  positioning  arm  disk  (PAD)l  or  tape.  These  are  the  only 
media  currently  supported  by  the  NRL  ASC  operating  system  although  other  mass  storage  sys- 
tem do  exist.  If  several  versions  exist,  then  some  can  be  on  tape  and  some  on  disk.  Note  that 
a node  which  has  no  versions  associated  with  it  contains  a null  set. 

Various  attributes  are  associated  with  nodes  and  versions.  The  attributes  associated  with  a 
node  allow  one  to  control  access  to  the  information  which  is  stored  there.  For  example,  the 
user  can  restrict  access  to  information  at  the  node,  and/or  reference  beyond  the  node  to  the 
sons.  The  "(J)ob  (S)pecification  (L)anguage"  manual  (#930038)  deals  with  this  subject,  and 
various  interactions  in  great  detail.  For  the  most  part,  users  will  not  need  these  facilities,  but 
they  are  available  if  the  information  is  sensitive  in  some  way,  or  simply  if  the  user  does  not 
want  random  people  accessing  the  files.  The  R.C.C.  note  #160  also  contains  some  information 
on  access  control.  Versions  also  have  attributes,  but  these  describe  the  format  in  which  the  in- 
formation is  stored.  A particular  version,  for  example,  can  be  in  physical  sequential  format 
with  logical  records  of  137  bytes  and  30  records  per  block.  This  type  of  information  would  be 
contained  at  the  version  level. 

In  order  to  store  information,  a node  must  first  be  created  and  then  versions  can  be  stored 
at  the  node.  Only  one  level  of  adding  or  deleting  can  take  place  with  a single  line  of  JSL.  Up 
to  sixty-four  versions  can  exist  at  a node.  Such  a feature  is  most  useful  for  maintaining  various 
edited  versions  of  a program.  Each  successive  version  can  be  an  updated  version  of  the  old 
program  or  program  file,  for  example. 

An  alternative  to  using  the  operating  system  to  keep  track  of  one’s  programs  is  for  the 
user  to  do  it  himself  This  can  only  be  done  on  tape,  however.  Files  which  are  created  (any  of 
those  disk  file  organizations  qualify  and  can  be  done  this  way)  can  be  put  on  tape  by  the  user, 
and  retrieved  in  a similar  fashion  Implementation  is  via  the  FIT  and  FOT  commands  (see  Sec- 
tion IV).  The  user  must  then  keep  track  of  the  files  in  a manner  similar  to  that  used  by  the 
operating  system  for  the  catalog  structure. 
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IV.  Job  Specification  Language 


The  Job  Specification  Language  (JSL)  is  the  means  of  telling  the  operating  system  what  is 
to  be  done  with  a job.  In  a sense,  it  is  a programming  language,  albeit  a fairly  primative  one. 
The  statements  specify  what  is  to  be  done  at  each  step  in  a job.  Actually,  the  job  stream  con- 
sists of  JSL  verbs  and  macros.  The  JSL  translator  decodes  these  statements  into  something  the 
operating  system  can  understand,  which  are  called  1 JSL  FRAMES  For  all  practical  purposes, 
JSL  verbs  and  macros  serve  the  same  function,  and  thus  macros  can,  for  the  most  part  be  treat- 
ed as  if  they  were  JSL  verbs.  JSL  verbs  tell  the  operating  system  what  to  do.  As  an  example, 
the  FD,  or  file  definition  verb,  specifies  some  information  to  be  passed  through  to  the  operating 
system  concerning  the  characteristics  of  a file,  such  as  the  type  of  organization  of  the  file. 
Referring  back  to  an  earlier  section,  the  appropriate  keyword  to  define  the  type  of  file  on  the 
FD  statement  would  be  FORG  = PS,  PD  or  DS.  which  tells  the  operating  system  that  the  file  is 
organized  according  to  the  physical  sequential,  partitioned  direct  secondary,  or  the  direct  secon- 
dary organization 

The  JSL  verbs  which  work  on  the  NRL  ASC  (#7)  are 

ASG,  ASGP,  CAT,  CATBLD.  CATN.  CATP,  CATV,  CHG,  DEL. 

DELV,  FD.  F1PT,  F1PTP.  FIT,  FITP.  FOPT,  FOPTP.  FOT.  FOTP. 

JOB,  LIMIT,  MAC  ASG,  MACBLD,  MLR.  MERE,  PJSL.  RPLV,  START, 

STOP.  XQT.  RENAME  and  REL 

and  the  system  macros  are 

ASM,  ASMC,  ASML,  ASM  LX,  ASMP,  CATLST,  CIFER.  CJSL.  DOCUMENT. 
DSDUMP,  DUMPER,  EOJ,  FILECNVRT,  FILF.COMP.  FILECOPY. 

FILEPTCH,  FILLST,  FOSYS.  FTN.  FTNL,  FTNLX,  FXOT.  LMPATCHER. 

LNK.  LNKX,  NEWF1LE,  NEWl.IB.  NEWPRINT.  NEWPUNCH.  OPT  PRTSS.  PDNLYZ, 
PDSCOL.  PDSDIR.  PDSLST,  PDSQSH.  PDSUPD,  PLAP.  SMS.  SMSASM, 

SMSASMC,  SMSASMP,  SMSI  TN.  SORT,  and  TPNLYZ 

System  macros  and  JSL  verbs  which  are  not  available  (or  do  not  currently  work)  on  ASC  (#7) 
are 

BATINT.  CNT/CNTE,  SETUP,  CFSTEP,  GET,  GETCAT, 

GETMEM,  MERGE,  PRNT.  PUNCH,  SAVE,  SAVF.CAT.  SAVEMEM,  and  SPLIT 


7 


Details  on  the  defaults  for  these  verbs  and  macros  can  be  found  in  the  "Job  Specification 
Language”  manual  (#930038)  and  the  "JSL  Systtm  Macros"  manual  (#930034).  The  R.C.C. 
computer  note  #105  also  has  the  locally  im  sed  defaults  listed.  This  too  is  a useful  reference 
manual. 

V.  Job  Structure  — Who  Does  What 

A JOB  is  structured  by  dividing  it  into  parts  which  the  operating  system  considers  similar, 
and  therefore  can  handle,  in  the  sense  of  not  biting  off  more  than  it  can  chew.  This  may  not 
be  identical  to  a programmers  idea  of  similarity,  but  in  order  to  understand  the  various  phases 
of  a job,  the  "OS"  point  of  view  must  be  considered.  A schematic  of  this  breakdown  is  shown 
in  Fig.  (1). 

A JOB  is  defined  by  a JOB  and  an  EOJ  pair.  In  between  there  are  phases  which  are 
defined  by  LIMIT  cards  (or  the  JOB/EOJ  pair  if  the  limit  defaults  are  used)  as  a block.  The 
usual  block  consists  of  a compile  followed  by  a link  and  then  an  execute  step.  This  is  not  fixed, 
however,  and  several  compiles,  links  and  execute  steps  can  be  combined  within  one  job  block, 
once  again,  defined  by  LIMIT  cards.  Alternatively,  each  step  can  be  in  its  own  block.  It  should 
be  pointed  out  that  the  resources  requested  affect  both  the  turnaround  of  a job,  and  the  amount 
it  costs  to  run  that  job.  Roughly,  the  more  resources  requested,  the  greater  the  cost,  and  the 
longer  the  wait. 

The  various  phases  have  to  run  through  both  a scheduler  (mix  table)  and  a real-time 
scheduler  which  actually  fits  the  requirement  of  the  job  into  the  system  and  runs  the  job.  In  a 
simplified  manner,  the  order  of  processing  a phase  of  a job  is  as  follows: 

(1)  Accept  the  job  from  an  input  device 

(2)  Scan  the  blocks  for  resources  required  and  grab  them  when  they  are  available 
(all  at  the  same  time)  — does  not  apply  to  memory  requests 

(3)  Process  the  EXECUTE  steps  of  a job 

(4)  Terminate  a job  by  spooling  appropriate  files  to  the  output  devices. 

For  the  interactive  jobs,  a block  is  the  set  of  JSL  which  is  appended,  [AP,  FILE]  at  the 


terminal. 
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The  job  is  accepted  by  an  input  device,  such  as  a card  reader,  and  is  put  into  the  initiation 
queue,  called  the  JIQ.  As  soon  as  the  operating  system  can  begin  to  search  for  the  requested 
resources,  then  the  job  is  moved  to  the  preprocessing  list,  or  PPL.  The  determination  to  move 
a job  from  the  JIQ  to  the  PPL  is  made  by  the  scheduler  on  the  basis  of  information  given  to  it 
by  the  job,  rather  than  on  the  actual  resources  which  are  to  be  used.  If  the  job  has  lied  at  this 
point,  there  is  a good  chance  that  the  PPL  scheduler  will  cancel  the  step  since  it  won’t  be  able 
to  find  the  necessary  resources.  This  applies  both  to  batch  and  interactive  job.  At  the  PPL,  the 
system  begins  to  grab  the  resources  necessary  to  run  the  job.  It  is  at  this  point  that  tapes  are 
fetched  from  the  library.  A job  will  not  leave  this  queue  until  all  resource  requests  (except 
central  memory)  are  satisfied.  This  is  to  prevent  a job  from  becoming  active  in  the  central  pro- 
cessor and  then  not  being  able  to  obtain  a tape  or  disk,  which  could  result  in  a hung  system 

Once  the  resource  requests  are  satisfied,  the  job  is  moved  to  the  active  job  list,  or  AJL.  It 
is  at  this  point  that  the  real  time  scheduler  attempts  to  fit  the  job  into  the  space  which  it  has 
available,  namely  the  maximum  central  memory  and  the  total  wall  clock  time  available  during 
the  day.  When  a job  is  on  the  AJL,  it  can  be  waiting  to  use  some  facility,  such  as  centtal 
memory,  or  it  can  actually  be  executing.  In  this  latter  case,  the  system  will  indicate  that  the  job 
is  in  STEP.  After  all  steps  have  completed,  the  job  goes  to  the  JBTL  list  where  it  is  ready  to  be 
spooled  to  the  output  devices.  As  soon  as  post  processing  has  finished,  such  as  temporary  files 
being  released,  and  output  files  (FOSYSed  files)  moved  to  the  output  queue,  the  job  is  passed 
to  the  JTBO  queue,  or  job  to  be  output  list.  At  this  point  the  remote  system  (RJE)  has  access 
to  the  job  and  print,  punch  and  plotting  are  done  as  necessary.  Interactive  jobs  are  handeled  in 
a similar  fashion,  except  they  loop  from  IJL  to  PPL  to  AJL  and  back,  and  the  mini-computer  (a 
TI  980)  which  interfaces  the  terminals  to  the  ASC,  maintains  its  own  list  of  active  jobs.  Figure 
(1)  shows  the  interaction  of  the  job  blocks  for  both  batch  and  interactive  jobs. 

The  workload  of  the  ASC  is  divided  among  it  various  components.  The  mainframe  itself 
is  divided  into  central  memory,  the  peripheral  processor  and  the  central  processor.  The  central 
memory  is  the  main  storage  unit  where  the  operating  system,  as  well  as  programs  which  are  ex- 


ecuting,  reside.  The  central  processor,  which  consists  of  a memory  buffer  unit  (MBU)  and  two 


r 

( 


arithmetic  units  (pipes)  handles  the  JSL  translator  as  well  as  user  programs.  When  a program 
is  in  STEP  in  the  AJL,  it  is  resident  in  central  memory  and  the  central  processor  is  taking  in- 
structions from  the  central  memory  in  an  order  determined  by  the  programmer.  A schematic 
diagram  of  the  main  components  of  the  ASC  is  shown  in  Fig.  (2). 

Except  for  the  JSL  translator,  the  operating  system  is  run  by  a unit  known  as  the  peri- 
pheral processor  Although  the  operating  system  instructions  are  in  central  memory,  the  actual 
work  is  done  by  the  PP  which  is  a separate  component  This  is  the  unit  which  handles 
INPUT/OUTPUT  requests,  transfers  data  from  disk-to-tape,  and  other  non-computation  orient- 
ed requests.  It  also  does  the  job  scheduling  and  account  processing.  This  computer  runs  in 
parallel  with  the  central  processor  and  the  only  interaction  is  through  the  central  memory  and 
some  special  control  registers.  Some  details  of  these  various  units  and  their  interaction  can  be 
found  in  the  manuals  "The  Programers  Guide  to  the  Peripheral  Processor"  (#930040),  "The 
ASC  Operating  System"  (#0545)  "Description  of  the  ASC"  (#934662-934666)  and  "Description 
of  the  ASC  Hardware"  (#929970) 

VI.  Running  a Job  — Basic 

The  main  goal  in  using  a computer  is  being  able  to  submit  a program  and  to  obtain  results 
with  a minimum  of  fuss  and  bother.  Some  examples  are  given  in  this  section  which  should  en- 
able a user  to  submit  a job  and  have  it  work  (barring  typing  errors  of  course).  It  is  assumed 
that  the  user  is  familiar  with  the  programming  language  FORTR  AN  This  is  the  primary  high 
level  language  in  use  on  the  ASC,  and  will  thus  be  used  for  examples  Other  languages  which 
are  available  are  ALGOL  (algol  60).  PASCAL.  COBOL,  ASC  CP  and  PP  assembly  language 
and  POPS,  soon  to  be  available  will  be  some  list  processing  languages  such  as  SNOBOL  or 
LISP 

Three  examples  are  given  below  Much  of  the  intermediate  output  which  the  user  will 
see  is  omitted  here  as  not  being  relevant  to  understanding  this  first  pass  through  the  world  of 
the  ASC  Much  of  it  is  useful,  however,  in  understanding  more  advanced  examples  and  for  op- 
timization and  debugging,  so  take  a look  at  it  now,  even  if  a very  cursory  look 
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The  first  example  deals  with  a self-contained  compile,  link  and  execute  step. 


1) 

2) 

3) 

4) 

5) 


6) 


7) 

8) 
9) 


/ JOB  JOBNAME, ACCOUNT  NO.,USERCODE,OPT10NS 
/ MACASG  MACRX1USERCAT/D77/L50/MACROS 
/ MFTN  COMPILER  — FX 

PROGRAM  EXAMPL 
CALL  COMMON 
WRITE  (6,101) 

101  FORMAT  ( FOR  THE  FIRST  TRY,  X - ') 

X - 3.0 

CALL  SUBA  (X) 

STOP  987 
END 

SUBROUTINE  SUBA  (ARG) 

WRITE(6. 101 ) ARG 
101  FORMAT  ( + .23X.F6.2) 

RETURN 

END 

/ MLNK 
/ MFXQT 
/ EOJ 


One  line  should  be  printed  by  this  program,  namely 

FOR  THE  FIRST  TRY,  X = 3 00 


#1  The  job  card. 

#2  Assigns  the  special  macros  discussed  in  Appendix  I 
#3  Invokes  the  fast  compiler  (FX)  on  the  program  following  it 

#4, #5  Specify  the  name  of  the  program  and  call  the  general  debugging  routine  COMMON 
#6  The  subroutine  SUBA,  called  in  the  main  program,  is  included  here 
#7  Invokes  the  linkage  editor  to  resolve  the  external  references  and  to  set  the  program 
up  into  executable  form 

#8  Loads  and  starts  the  program,  which  then  prints  the  above  line. 

#9  Terminates  the  job— at  RJE  sites,  this  must  be  followed  by  a card  with  the 
7/9  multipunch  in  column  one. 


An  extension  of  this  would  be  if  a subroutine  were  to  be  fetched  from  the  user's  library,  as 
shown  in  example  #2 


I 


K 


1) 

2) 

3) 

4) 

5) 


6) 


7) 

8) 
9) 


/ JOB  JOBNAME, ACCOUNT  NO.,USERCODE,  OPTIONS 
/ MACASG  MACRXJ,  USERCAT/D77/L50/MACROS 
/ MFTN  COMPILER -NX 
PROGRAM  E2 
DIMENSION  AGO, 10) 

CALL  COMMON 
NX  - 10 
NY  - 10 

DO  101  J - 1,  NY 
DO  101  I - 1,  NX 
101  A(1,J)  - FLOATG  + J) 

CALL  PRNT  ('  ARRAY  - A(U)  ’,A,NX,NY,1,NX,1,NY) 

STOP  123 

END 


/ ASG  PLIB,USERCAT/D77/L50/LIB,USE  — SHR 
/ MLNK 
LIBRARY  PL1B 
/ MFXQT 
/ EOJ 


This  program  will  print  out  a 10x  10  array  of  numbers  with  a heading. 

#l-#5  Same  as  previous  example 

#6  External  subroutine  — The  linkage  editor  must  fetch  this  from  a library 

#7  Tells  the  operating  system  to  use  the  access  name  "PLIB"  for  the  library 

at  the  node  "USERCAT/D77/L50/LIB" 

#8  Same  as  previous  example 

#9  Library  directive  for  the  linkage  editor 

The  program  E2  references  the  subroutine  PRNT  which  is  found  at  the  node 
USERCAT/D77/L50/LIB  The  linkage  editor  uses  the  access  name  PLIB  for  this  library.  Any 
other  valid  name,  such  as  XYZ12345,  could  have  been  used  as  well.  The  trick  here  is  that  the 
same  access  name  must  be  used  in  the  library  directive  statement  (#9)  as  was  used  in  the  as- 
sign statement  (#7).  The  third  example  is  that  of  fetching  a source  program  from  a tape  file, 
editing  and  compiling  this  program,  and  after  compiling  a main  program  and  a subroutine,  all 
with  different  compilers,  and  running  the  program,  as  in  previous  examples.  In  examining  the 
following  example,  the  reader  should  notice  that  no  explicit  reference  is  made  to  the  fact  that 
some  of  the  programs  reside  in  a tape  file 
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1)  / JOB  JOBNAME.  ACCOUNT  NUMBER,  USERCODE,  OPTIONS 

2)  / LIMIT  BAND-40 

/ MACASG  MACRX$S,USERCAT/D77/L50/MACROS 

3)  / ASG  SO.USERCAT/D77/B40/JONEW1/LIBRARY/SO.USE-SHR 

4)  / CIFER 

MERGE  SO,  PROG  1,  UPDATE 
SELECT  PLOTIT 
-1,2 

SUBROUTINE  PLOTPS!  A.NL.NC) 

-40 

C THIS  IS  AN  EDITED  VERSION  OF  PLOTIT 

NP  - 1 
NZ  - 0 
NUL  - 56 
NUC  - 101 
NSORT  - 0 
LEN  - 0 

TITLE  (1)  - SYM  (1) 

NPP  - 1 

XMAX  - -l.E  -I-  70 
YMAX  - -l.E  + 70 

5)  / REL  SO 

6)  / START  ACNM  — PROG2 

PROGRAM  DRIVER 
CALL  COMMON 
CALL  SUBB 
STOP  777 
END 

7)  / STOP 

8A)  / MFTN  COMPILER  =* NX,  IN  — PROG1 

8B)  / MFTN  COMPILER  = FX,  IN  = PROG2 

80  / MFTN 

SUBROUTINE  SUBB 
DIMENSION  XY (15,2) 

DO  1 I - 1 , 15 

1 XY (1,1 ) - FLOAT! I) 

READ! 5,2)  (X Y(l,2),l - 1 , 15) 

2 FORMATG5F4.0) 

CALL  PRNT(  RANDOM  NUMBERS  ,XY, 15, 2,1 ,15,1,2) 
CALL  PLOTPS(XY,15,2) 

RETURN 

END 

9)  / PD  LOCALP,  USERCAT/D77/L50 

10)  / ASG  PLIB,  LOCALP/LIB,  USE  - SHR 

11)  / MLNK 
LIBRARY  PLIB 

12)  / MFXQT  DATA  — WHATEVER 

13)  / START  ACNM-WHATEVER 

0 1 1.321  1 17.209  435  100  017  100  173.332.224  446  666  370  45 
/ STOP 
/ EOJ 
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This  example  will  produce  a printout  of  the  data  together  with  a plot  of  the  same  data. 


1 


r 


#1  Job  card 

#2  Allocation  of  40  bands  of  HPT  (head  per  track  disk)  for  this  job 
#3  Assign  the  source  library  to  the  access  name  SO 
#4  Invoke  the  editor  CIFER 

#5  Release  the  source  file  after  we  are  finished  with  it 

#6-#7  A START/STOP  file  which  contains  the  main  program 

#8  Three  compile  steps  with  various  combination  of  compilers  and  input  files 

#9  A (P)ath  (D)elinition  to  save  typing  later  on 

#10  Same  as  #7  in  the  previous  example 

#12  An  execute  with  the  input  coming  from  the  file  WHATEVER 

#13  A START/STOP  file  to  define  the  input  data  for  the  file  WHATEVER 

The  extra  disk  space  allocation  required  by  this  tape  assign  (#2)  is  the  problem  referred  to  ear- 
lier, namely  that  tape  staging  requires  the  allocation  of  disk  space,  since  the  file  does  not 
currently  reside  on  the  disk.  The  user  reserves  the  necessary  scratch  space  with  the  limit  card. 
Line  #5  then  releases  the  file  when  it  is  no  longer  necessary  to  have  it  available,  so  that  the 
disk  space  can  be  used  later  Note  that  no  explicit  reference  is  made  to  the  fact  that  this  is  a 
tape  file,  and  the  only  way  to  know  this  is  to  check  the  job  activity  list  to  find  the  tape  number 
that  was  used  in  the  mount  request  for  the  operator. 

This  example  also  gives  a short  lesson  in  how  to  use  one  of  the  source  file  editors,  in  this 
case,  CIFER.  Since  the  compilers  take  the  programs  in  PS  organization,  and  a library  is  in  the 
PDS  organization,  the  editor  is  used  to  make  the  switch  via  the  MERGE  command.  The  partic- 
ular program  that  is  wanted  is  SELECTed  The  access  name  for  this  program  becomes  PROG1 
rather  than  SO.  Also  shown  are  two  examples  of  START/STOP  files.  The  only  restriction  on  a 
START/STOP  file  is  that  another  START/STOP  file  can  not  be  embedded,  and  JOB/EOJ  must 
be  paired.  This  JSL  verb  is  used  to  insert  PS  files  into  the  job  stream. 

Several  types  of  compiles  are  shown,  with  both  the  NX  (the  default)  and  the  FX  compiler 
being  used.  In  the  first  two  cases,  the  programs  (PROG1  and  PROG2)  are  defined  elsewhere, 
but  for  the  third  compile,  the  program  comes  from  cards  which  follows  the  MFTN  card.  An 
example  of  the  PD  or  path  definition  is  given  in  line  #9.  After  this  JSL  verb  is  used,  the  name 
LOCALP  can  be  used  wherever  the  path  USERCAT/D77/L50  was  used  earlier.  This  particular 
example  does  not  fully  demonstrate  the  time  saving  that  this  command  can  have,  but  after  a 
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while,  ihe  user  will  realize  the  benefit. 


These  three  examples  are  probably  sufficient  for  a first  pass  through  the  world  of  the  ASC 
computer  Once  these  examples  have  been  tried,  and  prior  to  creating  files  (examples  of  which 
are  given  in  the  next  section),  it  would  be  worthwhile  reading  the  earlier  sections  on  libraries 
and  file  structure 


VII.  Running  a Job— Advanced 

It  has  been  stressed  repeatedly  that  the  catalog  system  of  the  ASC  obviates  the  need  for 
large  card  decks.  As  an  extension  of  section  (VI)  it  will  be  shown  how  this  can  be  done  with 
the  least  fuss  and  bother  C1FER  will  be  the  editor  used  as  an  example,  and  it  will  be  used  to 
modify  FORTRAN  source  modules  The  technique  here,  however,  is  that  of  manipulating 
files,  and  not  one  of  espousing  the  virtues  of  one  source  module  editor  over  another,  or  one 
language  over  another  The  examples  will  start  with  the  process  of  creating  a file,  and  from 
that  point  modifying  this  file  to  obtain  various  results. 

The  first  example  begins  with  the  program  given  in  example  #3  of  the  previous  section 


F 


£; 

f 
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1) 

2) 


3) 


/ JOB  JOBNAME,  ACCOUNT,  USFRCODE,  OPTIONS 
/ LIMIT  BAND  - 40 

/ MACASG  MACRX,  USERCAT/D77/L50/M ACROS 
/ PD  U,  USERCAT/D77 

/ ASG  CIFER,  U/L50/CIFF.R,  USE  - SHR 

/ ASG  SO.  U/B4Q/JONF.W1/LIBRARY/SO.  USE  - 

/ CIFER 

COPY  SO,  NEWSO.  UPDATE 

SELECT  PLOTIT 

-1,2  SUBROUTINE  PLOTPS  IA.NL.NC) 

-40 


NP  - 1 
NZ  - 0 
NUL  - 56 
NUC  - 101 
NSORT  = 0 
LEN  - 0 
NPP  - 1 

TITLE  (1)  - SYM  (1) 
XMAX  - -I  E + 70 
YM AX  - -I  E + 70 
4)  SPLIT  *,  NEWSO 

PROGRAM  TEST  1 
CALI  COMMON 
CALL  SUBB 
STOP  777 
END 


5) 

/ 

PRINT 

PD 

NEWSO 

MYPATH.  USERC AT/Dnn/Bmm/USERCl 

6) 

/ 

CATN 

MYPATH/TEST 

7) 

/ 

CATN 

MYPATH/TEST/SO 

8) 

/ 

CATV 

MYPATH/TEST/SO.  ACNM  - NEWSO 

/ 

EOJ 

SHR 


#1  Path  definition  to  reduce  typing  in  the  following  two  lines. 

#2  Assign  the  new  version  of  the  CIFER  program  because  it  runs 
faster  and  costs  less 

#3  A CIFER  verb  to  take  a SELECTed  source  module  - in  this  case 
PLOTIT  - and  move  it  from  the  library  file  SO  to  the  library- 
file  NEWSO 

#4  A CIFER  verb  to  examine  the  following  cards  images  (*) 
and  also  place  them  in  NEWSO  with  module  names  given 
by  the  names  found  in  the  PROGRAM.  SUBROUTINE 
and  FUNCTION  cards 

#5  Path  definition  appropriate  to  the  user 

#6  Define  a node  called  TEST,  under  the  users  path 

#7  Define  a node  called  SO,  under  TEST 

#8  Catalog  the  library  file  NEWSO  at  the  node  MYPATH/TEST/SO 
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This  example  is  designed  to  illustrate  the  mechanics  of  creating  a library  file  of  source 


modules  and  cataloging  it  on  disk,  as  a version,  at  the  node 

USERCAT/Dnn/Bmm/USERCl  /TEST/SO. 

The  assumption  made  here  that  the  user  has  registered  an  account  number  at  the  Work  Control 
Center,  and  thus  has  obtained  the  names  which  correspond  to  Dnn,  Bmm  and  USERC1.  This 
notation  will  be  assumed  from  now  on,  and  the  appropriate  substitution  should  be  made. 

As  for  the  example  itself,  two  facts  stand  out:  first,  as  noted  previously,  only  one  level  of 
catalog  structure  can  be  added  or  deleted  with  a given  line  of  JSL,  ana  consequently,  both  lines 
#6  and  #7  are  required;  secondly,  that  the  user  wishes  to  use  the  same  name  for  the  source 
modules  as  is  given  to  the  program  (line  #4).  It  is  a simple  matter  to  use  alternative  names  for 
the  modules  by  inserting  appropriate  directive  cards  just  before  each  program.  Such  is  not  done 
in  this  example  for  simplicity:  there  are  already  three  distinct  names  to  worry  about,  and  adding 
a forth  distinct  name  to  distinguish  source  modules  and  program  names  will  not  help  under- 
standing. The  three  names  are  (1)  node  name  (SO),  (2)  temporary  file  name  (NEWSO),  and 
(3)  program  and  module  names  (PLOTIT  and  TEST1).  The  bottom  line  is  that  a source  file 
now  exists,  with  two  programs  contained  in  it,  in  a library  format.  The  next  example  shows 
how  to  add  another  routine  (SUBB)  and  edit  one  of  the  original  source  modules.  These  three 
programs  are  then  compiled,  saved  as  updated  source  and  object  files,  and  the  load  module  is 
executed. 


/ JOB 

/ MACASG  MACRX  $$,  USERCAT/D77/L50/M ACROS 


/ PD 

U,  USERCAT/D77/L50 

/ PD 

ME.  USERCAT/Dnn/Bmm/USERCl 

/ ASG 

CIFER,  U/CIFER,  USE  - SHR 

/ ASG 
/ CIFER 

SO.  ME/TEST/SO,  USE  - SHR 

1) 

MERGE 

SO, SYS  FIN,  UPDATE 

SELECT 

TESTI 

SELECT 

PLOTPS 

2) 

-41,41 

NUL  - 26 

3) 

COPY 

V SYS  FIN 

SUBROUTINE  SUBB 
DIMENSION  X Y ( 1 5.2) 

DO  1 1 - I,  15 

1 XY  (I.  1)  - FLOAT  (I) 

READ  < 5.  2)  (XY  (I,  2),  I - I.  15) 

2 FORMAT  (1 5F4  0) 


CALL  PRNT  ( RANDOM  NUMBERS’,  XY,  15,  2,  I,  15,  1,2.) 
CALL  PLOTPS  (XY,  15.  2) 

RETURN 

END 


4) 

/ MFTN 

COMPILER  - FX 

5) 

/ FD 

SYS  FIN,  POS  - NEW 

/ FD 
/ CIFER 

SYS  OMOD.  POS  - NEW 

6) 

SPLIT 

SYS  FIN,  NEWSO 

SPLIT 

SYS  OMOD.  NEWOB 

7) 

/ CATN 

ME/TEST/OB 

8) 

/ CATV 

ME/TEST/SO,  ACNM  - NEWSO 

/ CATV 

ME/TEST/OB,  ACNM  - NEWOB 

/ ASG  PLIB,  U/LIB,  USE  - SHR 
/ MLNK 
LIBRARY  PLIB 
9)  / MFXQT 

111  123  9871  1 10  02  1731  02  101  632  777  851  233  921  651  333 
/ EOJ 


#1  Reformat  the  source  file  from  the  PDS  format  to  the  PS  format  while 

copying  it  to  the  temporary  file  SYS  FIN.  and  doing 
updates  on  the  modules 

#2  Change  the  number  of  lines  in  the  output  of  the  routine  PLOTPS 

#3  Copy  the  following  cards  ( on  card  images)  into  SYS  FIN 

#4  Compile  all  the  programs  with  the  FX  compiler  Note 

that  the  default  input  for  the  compiler  is  SYS  FIN 

#5  Poslton  the  file  pointer  to  the  beginning  of  the  file  for 

use  by  CIFER 

#6  The  CIFER  verb  to  reformat  the  physical  sequential 

files,  SYS  FIN  and  SYS  OMOD,  into  the  PDS  formated  files 
whose  names  are  NEWSO  and  NEWOB 
#7  Create  a node  called  OB  under  the  path  ME/TEST 

#8  Replace  the  old  contents  of  SO  with  the  contents 

of  the  file  NEWSO 

#9  Execute  the  load  module  which  has  been  created  by  the  MLNK  step 
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This  example  shows  one  means  by  which  a user  can  (1)  edit  a source  module,  (2)  add 
another  source  module  to  the  file  and  (3)  run  the  entire  setup.  In  adddition,  the  object 
modules  have  been  saved  at  the  node  TEST/OB  and  will  be  used  in  the  next  example  to 
demonstrate  the  use  of  object  libraries  to  save  recompiling  source  modules  from  one  execution 
to  the  next. 

Another  example  of  manipulating  these  files  is  to  use  the  same  subroutines  with  another 
main  program. 


/ JOB  

/ MACASG  MACRX  $$,  USERCAT/D77/L50/MACROS 
/ PD  U.USERCAT/D77/L50 
/ PD  MYPATH,  USERCAT/Dnn/Bmm/USERCl 
/ ASG  CIFER,  U/CIFER,  USE  - SHR 
/ ASG  SO,  MYPATH/TEST/SO,  USE  - SHR 
#1)  / ASG  OB,  MYPATH/TEST/OB,  USE  - SHR 
/ CIFER 

..COPY  *,  SYS. FIN 
#2  PROGRAM  TEST  2 

CALL  COMMON 
PRINT  1 

1 FORMAT  (‘THIS  IS  TEST  #2'  ) 

CALL  SUBB 

PRINT  2 

2 FORMAT  <TF  THIS  MESSAGE  IS  PRINTED.  THERE  IS  AN  ERROR’) 
STOP  69 

END 

MERGE  SO.  SYS  FIN 
#3  SELECT  PLOTPS 
-41,42 

NUL  - 36 
NUC  = 51 
STOP  777 

/ MFTN  COMPILER  = FX 
/ ASG  PLIB.  U/LIB,  USE  - SHR 
/ MLNK 

LIBRARY  OB,  PLIB 
/ MFXQT 

.123.456.789.123.456.789.456  123.777.888.999.965.386.451.010 
/ EOJ 


#1  Assign  the  object  file  library 

#2  Insert  a new  main  program 

#3  Modify  the  plot  routine 


This  example  adds  a new  driver  program  and  modifies  the  plotting  routine  to  stop  inside  it 


rather  than  returning  to  the  main  program.  If  the  update  is  done  incorrectly,  a message  to  that 
effect  will  be  printed  on  the  output  file.  The  final  example  shows  the  means  of  deleting  files 
once  they  are  no  longer  needed.  The  test  files  will  now  be  deleted,  since,  once  the  user  has 
found  his  way  to  this  point,  there  is  no  longer  a need  for  these  programs. 


/ JOB 

/ PD  ME,  USERCAT/Dnn/Bmm/USERCl 

/ DEL  ME/TEST/SO 

/ DEL  ME/TEST/OB 

/ DEL  ME/TEST 

/ EOJ 

The  only  point  that  needs  to  be  emphasized  here  is  that  OB  and  SO,  which  are  sons  of  TEST, 
must  be  deleted  prior  to  deleting  TEST. 

At  this  stage,  the  user  should  be  ready  to  tackle  most  JSL  problems  which  arise.  The  use 
of  more  advanced  capabilities  requires  perusal  of  the  various  manuals  and/or  inquiring  about 
the  system  from  an  R.C.C.  consultant  or  some  other  knowledgeable  individual. 

VIII.  Errors  and  Debugging 

Errors  fall  into  three  categories:  first,  there  are  the  simple  mistakes  such  as  bad  JSL  or 
mispunched  data,  insufficient  disk  space  or  execution  time  allocation,  etc.,  next  are  the  normal 
errors  which  this  section  will  address  in  some  detail.  These  first  two  types  of  errors  comprise 
about  99%  of  all  problems  and  includes  such  idiocy  as  not  initializing  variables.  Finally,  there 
are  the  difficult  errors  which  require  postmortem  dumps.  This  latter  type  of  error  usually  ac- 
counts for  less  than  0.1%  of  the  errors  and  resorting  to  such  drastic  debugging  techniques 
should  be  avoided  unless  all  else  fails.  It  is  possible  to  save  postmortem  dumps  on  disk  or  tape 
and  such  a procedure  is  a useful  technique  for  expensive  jobs  or  those  that  require  a long  turn 
around. 

The  simple  errors  are  usually  a result  of  overlooking  some  detail.  This  type  of  error  can 

be  ferreted  out  by  looking  through  the  activity  file  and  the  output  from  each  of  the  steps.  Usu- 
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ally  problems  such  as  forgetting  to  allow  enough  disk  space,  step  time  or  even  not  having  the 
correct  program  available  can  be  found  here.  Most  of  these  errors  can  be  solved  rather  easily 
although  occasionally  one  encounters  an  error  message  or  diagnostic  which  is  quite  obscure. 

The  first  step  is  to  examine  the  job’s  activity  file  (SYS.JATF).  Termination  codes  (re- 
ferred to  as  TERM  CODES  or  TC)  greater  than  zero  are  likely  candidates.  Also  error  messages 
will  sometimes  be  printed  if  the  operating  system  can  figure  out  what  the  problem  is  Typical 
of  this  class  of  problem  is  the  message  ATTEMPED  DISC  ALLOCATION  FOR  FILE 
SYS.PRT.  CURRENT  ALLOCATION  FOR  JOB  EXCEEDS  LIMIT  FOR  DISC  RESERVA- 
TION TYPE  HPT.  INCREASE  DISC  LIMIT.  For  problems  of  this  type,  the  solution  is  usual- 
ly indicated,  as  in  the  above  example. 

The  greatest  part  of  this  section  will  be  devoted  to  solving  user  errors  of  the  intermediate 
type,  namely  those  that  do  not  fall  into  the  first  category,  but  that  can  be  solved  with  some 
detective  work. 

There  are  two  principle  sources  of  errors  which  can  appear.  First  are  the  errors  detected 
by  the  hardware,  for  example  when  ones  attempts  to  divide  by  zero.  Second  are  the  software 
(program  generated)  errors.  The  latter  usually  come  from  either  the  ASC  MATHPACK.  or 
from  ABEND  requests  generated  by  one  of  the  language  processors. 

Of  the  latter  type  of  error,  namely  those  due  to  software  procedures,  the  language  transla- 
tor ABEND’S  are  solved  simply  by  correcting  the  syntax  of  the  program.  The  termination  mes- 
sage, which  will  be  found  in  the  JSL  summary,  will  be  something  like  ABEND  FLAG 
DETECTED,  TERM  =»  10.  For  the  other  variety  of  software  error,  most  commonly  numerical 
errors  which  are  detected  by  the  system  software,  there  is  no  handy  way  to  pinpoint  the  source 
of  troubles.  An  example  of  a numerical  error  would  be  an  attempt  to  find  the  square  root  of  a 
negative  number.  Although  the  associated  traceback  will  indicate  which  routine  was  invoking 
the  procedure,  there  is  no  handy  means  to  find  which  line  of  code  actually  called  the  routine 
Even  if  one  knew,  there  might  will  be  sonic  indirect  effect  which  caused  this  error  in  the  first 

place.  A procedure  to  find  the  actual  fine  of  code  is  discussed  later  and  involves  decoding  the 
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base  registers,  B1  in  partieular.  Numerical  errors  are  most  often  caused  by  not  understanding 
the  limitations  of  the  computer,  the  mathematics  routines,  or  even  sometimes  an  outright  er- 
ror, such  as  over  writing  data.  The  traceback  which  is  printed  is  supposed  to  be  a handy  guide 
for  finding  the  offending  source  code,  but  usually  succeeds  only  in  locating  the  routine  where 
the  offending  data  was  found,  and  in  many  cases  is  rather  obscure.  The  quickest  way  to  find 
the  source  of  this  type  of  error  is  to  put  print  statements  in  the  program  about  where  one 
thinks  the  errors  occurs.  This  is  not  a very  satisfactory  procedure,  but  usually  works. 

The  types  of  errors  which  are  amenable  to  being  solved  on  the  spot  are  known  as 
hardware  errors  and  consist  of 

#1  DIVIDE  CHECK  - dividing  by  zero 

#2  FLOATING  POINT  OVERFLOW  - exceeding  the  upper  limit  of  the 

floating  word  characteristic  ( =73) 

#3  FLOATING  POINT  UNDERFLOW  - exceeding  the  lower  limit  of  the 

floating  word  characteristic  ( = — 72  ) 

#4  FIXED  POINT  OVERFLOW  - an  integer  operation  which  yields  a 

number  larger  than  10"-1 

#5  PROTECTION  VIOLATION  - accessing  outside  a user's  area 

#6  ILI  EGAL  INSTRUCTION  - very  unusual  and  will  not  be  discussed  here 

#7  TIME  OUT  - no  explanation  needed 

There  is  a mask  which  determines  which  of  the  arithmetic  errors  (#1  — #4)  will  be 
trapped  by  the  arithmetic  unit  and  which  will  be  ignored  It  is  set  either  by  the  user  at  the  time 
the  program  is  translated  (compiled)  or  when  the  program  is  executing  This  mask  is  called  the 
ARITHMETIC  EXECPTION  MASK  and  is  set  by  the  C or  U options  when  using  the  FOR- 
TRAN compilers.  Assembly  language  users  have  to  set  it  themselves.  A couple  of  examples 
will  probably  be  sufficient  to  illustrate  how  to  find  the  offending  source  code  which  yields  one 
of  these  errors  Errors  of  the  type  #5  or  #6  are  generally  not  under  programmer  control,  but 
can  be  debugged  in  a similar  fashion. 

There  are  several  debugging  routines  available  to  help  find  the  cause  of  the  above  errors, 
but  the  most  useful  and  easiest  to  understand  is  called  COMMON.  It  is  on  the  Scientific  Pro- 
gram Library  under  the  guise  of  debugging  routines.  No  special  effort  is  needed  to  obtain  it  ex- 
cept to  CALL  COMMON  Other  aliases  are  MFDUMP,  MFW1C.  and  HUMPTY  (DUMPTY). 
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One  of  the  primary  advantages  of  this  routine  over  others  is  that  it  is  protected  against  destruc- 
tion by  the  user,  so  even  in  cases  where  a complete  o er  write  of  central  memory  occurs,  some 
information  should  be  returned.  The  examples  which  ar_  given  below  will  use  this  routine  for 
purposes  of  explanation. 


To  illustrate  the  use  of  a traceback,  we  will  use  the  following  FORTRAN  example 


100 

PROGRAM  BLECH 

COMMON  NX,NY,DX,A(  100) 

CALL  COMMON 

DX  = 0.0 

DO  100  1=1,  100 

Ad)  = FLOAT  (I) 

101 

X = 0.0 

DO  101  I = 1,  100 

X - X + 1. 

102 

DO  102  1 = 1.  100 

A ( I ) = A(1)/DX 

103 

WRITE  (6,  103)  A,  DX 

FORMAT  (IX,  IP10G12.3) 

STOP 

END 

The  first  example  will  be  one  of  a trackback  when  the  FX  compiler  has  been  invoked  and  the 
second  example  will  be  with  the  NX  compiler  at  level  "K".  the  vectorization  level. 

Figure  (3)  shows  the  output  from  the  mini-dump  generated  by  COMMON.  The  Program 
Status  Word  points  to  location  (441).  As  mentioned  earlier,  this  will  usually  be  ahead  of  the 
actual  location  of  the  error  although  branch  instructions  can  modify  the  sequence.  Since  the  er- 
ror is  a DIVIDE  CHECK,  one  should  look  for  instructions  which  involve  floating  point  arith- 
metic. and  in  particular,  divide  instructions.  One  occurs  at  absolute  location  (445),  or  relative 
location  (045).  This  latter  information  is  available  if  the  macro  MLNK  has  been  used.  The 
name  of  the  routine  is  BLECH  (as  expected  since  we  had  only  the  one  main  program).  Look- 
ing at  the  CSN/LOCATION  listing  produced  by  MFTN,  Figure  (4),  we  can  see  that  this 
corresponds  to  CSN  1 1 This  can  be  checked  for  this  particular  problem  since  the  FX  compiler 
was  used  Once  again,  examining  the  mini-dump,  one  can  see  that  CSN  1 1 was  also  given  by 
the  FX  compiler.  As  expected,  this  refers  to 
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102  A(l)  = A(1)/DX. 


A lesi  using  ihis  same  example  with  the  NX  compiler  will  demonstrate  this  same  technique  for 
vector  parameter  tiles  (VPF)  alt  lough  in  this  case  the  correct  CSN  will  not  be  directly  available 
since  the  NX  compiler  does  not  provide  this  information.  Figure  (5)  shows  an  equivalent 
mini-dump  of  the  example  program.  Two  VECT  instructions  appear  at  or  prior  to  the  PSW  lo- 
cation  and  thus  are  candidates  for  the  fault.  Examination  of  the  offset  - see  Appendix  II  - re- 
veals  that  the  offsets  (relative  to  the  READ  ONLY  area)  are  (20)  and  (28).  Figure  (6)  shows 
the  VPF's  for  this  program  The  offset  is  given  in  the  upper  left  hand  corner,  as  shown  in 
Tables  (111)  and  (IV).  The  VPF  which  corresponds  to  the  floating  divide  is  the  second  one  and 
this  is  generated  at  CSN  Relering  to  the  compilation  in  Figure  (7),  we  see  that,  once  again, 
the  divide  operaiton  is  found  to  be  the  culprit. 

One  final  example,  to  show  the  effect  of  a PV  or  protection  violation,  will  be  given. 


COM  MON/DATA/NX,  NY 
CALL  COMMON 
NX  = 1000  000 
CALL  SUBA(X) 

STOP 

END 

SUBROUTINE  SUBA(X.Y) 
C'OMMON/DATA/NX. NY 
REAL  X < 1 ) 

Y = X(NX ) 

RETURN 

END 


The  above  example  generated  the  mini-dump  shown  in  Figure  (8).  Going  through  the 
same  procdurc.  as  before,  we  see  that  the  PV  was  caused  by  the  instruction 


L A0  (000,  BF),  X4 

To  confirm  that  it  was  the  Y = X(NX)  instruction  which  caused  this  problem  the  offset  is 
(028)  from  the  base  register  B2,  and  it  is  indexed  by  index  register  XI.  XI  contains  the  index 
of  1000  000  which  is  clearly  outside  the  program's  area. 
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This  should  be  a useful  start  On  final  point  which  will  help  in  reading  these  trackbacks  in 


that,  in  general 

B1  = subroutine  return  address  (generated  by  a BIB) 

B2  = READ/WRITE  address 
B3  = READ  ONLY  address 
B4  BS  = Address  of  FIO  routine  if  FIO  is  used 
Bb-B7  = are  common  areas 

B8-B1 5 = are  branch  addressses  or  common  areas  as  necessary 

I 

The  above  "B’s"  refer  to  base  registers  in  the  register  dump  portion  of  the  mini-dump 
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APPENDIX  I.  - EXPLANATION  OF  MACROS 

JSI  statements  are  used  to  specify  what  action  the  operating  system  is  to  take  for  each 
part  of  the  job  stream  If  one  were  to  use  the  JSL  only,  he  would  find  that  certain  combina- 
tions occurred  repeatedly  Such  groups  of  JSL  can  be  combined  and  put  in  a form,  with  its  own 
name,  that  is  similar  to,  and  will  be  processed  just  as  if  it  were  a JSL  verb  This  combination  of 


JSI  will  be  processed  each  time  the  given  name  is  used  Such  a structure  is  called  a MACRO. 
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The  lorm  of  a call  which  invokes  a macro  is  identical  to  that  for  a JSL  verb,  and  in  fact,  the 
oame  translator  and  syntax  checker  is  used  for  both. 


There  is  a set  of  macros  which  the  system  maintains  for  all  users  (a  list  of  these  is  found 
in  Section  IV).  The  user  may  also  maintain  his  own  set  of  macros  to  perform  special  functions 
which  are  relevant  to  his  own  environment.  In  addition  to  the  system  macros,  which  come 
from  the  macro  file  whose  access  name  is  SYS.MCRO,  there  is  a useful  set  of  macros  at  the 
node 

USF.RCAT/077/L  50/ MACROS 

this  includes  the  macros  MFTN,  MLNK,  MFXQT,  ASG,  GET,  PUT,  OUTPUT  and  CAT- 
MAN.  To  use  these  macros,  use  the  following  MACASG  card 

/ MACASG  MACRX  $S.  USERCAT/D77/L50/M ACROS 

and  make  the  following  replacements 

FTN  — MFTN 
LNK — MLNK 
FXQT  - MFXQT 

The  remaining  macros  have  no  system  equivalent,  so  that  they  are  used  as  is.  The  individual 
macros  and  how  they  are  used  is  explained  below.  The  purpose  of  these  macros  is  to  provide 
the  user  more  information,  in  a compact  form  (to  save  paper  and  storage),  without  undue  bur- 
den on  the  user  Also,  these  macros  have  as  defaults  the  options  which  are  most  commonly 
used,  thus  saving  the  beginning  user  from  having  to  learn  the  entire  system  prior  to  using  it. 

MFTN  MACRO 

The  purpose  of  the  MFTN  macro,  which  is  used  to  invoke  the  FORTRAN  compiler,  pro- 
vides just  a little  bit  more  information  than  provided  by  the  standard  FTN  macro.  This  makes 

debugging  a program  very  much  simpler  and  faster  The  cost  is  about  10%  more  than  the  stan- 
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dard  compile  without  the  "O"  option.  The  "O"  option  is  required  if  options  are  selected  as  in 


FTNOPT  — ( O) 


and  the  default  is 


FTNOPT-  (K,M,U,V,D,Y,0). 


There  are  six  noteworthy  points: 


(1)  It  yields  a similar  listing  to  FTN,  but  also  includes  a summary,  at  the  end  of  the  source 
listing,  of  CSN  versus  relative  core  location  in  the  program 

(2)  In  addition,  the  vector  parameter  files  are  printed  at  the  end  of  the  source  listing.  In 
finding  errors  in  vector  instructions,  this  shows  exactly  what  variables  are  being  used  when 
the  computer  quits  in  the  middle  of  a vector  operation  When  an  error  occurs  during  a vec- 
tor operation,  the  particular  vector  being  used  can  be  found  by  using  the  traceback  routine 
COMMON.  The  form  of  the  vector  parameter  file  and  what  each  of  the  entries  is  used  for 
is  explained  in  Appendix  II. 

(3)  It  modifies  SYS.OMOD  to  identify  the  compiler  and  compiler  options  used  and  places 
this  information  in  the  "I"  card  of  the  object  module.  When  a program  is  linked,  this 
information  shows  up  in  the  link  map. 

(4)  It  allows  the  user  to  select,  rather  easily,  his  favorite  compiler. 

(5)  Allows  the  user  to  use  a non-standard  list  file  (LIST  = . . .)  without  having  to  give  FD 
cards. 

(6)  Allows  the  user  to  branch  to  specific  parts  of  the  job  stream  on  the  basis  of  compiler 
error  termination  codes  (e  g.  TERM  - 8 ). 


The  various  options  for  the  MFTN  macro  are  shown  in  Table  (I)  with  the  default,  if  there 
is  one,  shown  in  parenthesis 


The  primary  differences  between  the  MFTN  macro  and  the  FTN  macro  are  the  set  of 
three  keywords:  COMPILER,  DOCUMENT  and  SAVE  and  a different  choice  of  compiler 
defaults.  The  first  one,  COMPILER  allows  one  to  choose  the  favorite  compiler.  Note,  how- 
ever, the  interaction  with  the  keyword  FTVERS,  which  overrides  this  option  The  second  key- 
word, DOCUMENT,  which  is  also  available  as  the  first  positional  parameter,  yields  a short  list 

of  the  options  and  their  defaults.  The  third  option,  namely  SAVE-YES  or  SAVE  — NO,  will 
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save  the  original  object  deck  in  the  unmodified  form  at  the  access  name  SYS.NMOD  The 
defaults  for  FTN  are  FTNOPT  = (K,M.O)  and  for  MFTN,  FTNOPT  = (K,M,N,V,D,Y,0). 

The  only  known  problem  is  that  when  too  little  disk  space  is  provided  for  the  list  file  in 
the  MFTN  step,  the  routine  WRITFL  will  timeout.  The  solution  is  to  provide  enough  space. 
Note  that  the  LIMIT  card  as  well  as  LISTSIZE  play  a role  in  disk  space  determination. 

The  compilers  which  are  currently  available  (2/12/79)  are  NX0509,  NX0514,  NX0522, 
NX0526.  NX0527.  NX,  NEWNX,  FX0518,  FX0526,  FX  and  NEWFX.  The  current  compilers 
are  NX  and  FX  and  experimental  versions,  if  they  exist,  are  called  NEWNX  and  NEWFX. 


MLNK  MACRO 


The  purpose  of  the  MLNK  macro,  which  is  used  to  invoke  the  linkage  editor,  is  threefold 
firstly,  it  provides  all  of  the  normal  functions  of  the  linkage  editor  as  in  I NK  secondly,  the 
output,  SYS.PRT,  is  much  more  compact  and  readable  If  additional  information  is  ever 
needed,  it  is  a simple  matter  to  execute  a second  LNK.  thirdly,  the  intermediate  file  LNK  PRT 
provides  useful  information  to  the  debugging  routine  COMMON  to  yield  relative  program 
addresses  and  special  diagnostics  il  a program  tails  while  in  a system  routine  The  parameters 
are  shown  in  Table  (II),  with  their  delaults  shown  in  parenthesis 

MFXQT  MACRO 

The  MFXQT  macro  is  a similarity  extension  of  the  two  preceeding  macros  (MFTN  and 
MLNK)  and  is  identical  to  the  FXQT  macro  except  that  it  manipulates  the  files  LNK  PRT  , 
FT98F097  and  FT98F098  for  use  by  the  debugging  routine  COMMON  If  this  routine  is  not 
used,  or  no  error  occurs,  then  the  differences  between  these  two  macros  are  negligible  All 
options  and  keywords  are  the  same  as  for  FXQT 

If  one  wishes  to  duplicate  the  functions  of  this  macro  using  the  FXQT  macro,  the  first 
order  of  business  would  be  to  FOSYS  the  file  FT98F098  after  the  XQT  verb  was  processed,  i e .. 

/ FXQT 

/ FOSYS  FT98F098 

The  second  iteration  introduces  the  subtlety  of  defining  FT98F097  and  renaming  LNK. PRT  to 
this  access  name.  It  is  simpler,  however,  to  use  MFXQT  in  place  of  FXQT 
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ASG  MACRO 


The  JSL  verb  ASG  requires  the  specification  of  the  USE  parameter,  with  the  default  being 
USE  - EXC  - exclusive.  Since  most  users  prefer  the  other  option,  namely  USE  — SHR  - 
share,  a macro  is  used  to  replace  this  JSL  verb.  It  is  identical  to  the  verb  itself,  except  the 
default  is  SHR,  so  the  user  need  not  type  this  extra  bit  of  informaiton  each  time  an  assign  com- 
mand is  done.  It  must  be  emphasized,  however  that  this  macro  resides  only  at  the 
L50/MACROS  node  and  is  not  part  of  the  system  macro  file. 

CATMAN  MACRO 

This  is  a macro  and  associated  program  to  generate  the  necessary  JSL  to  manipulate 
cataloged  files.  Its  most  useful  feature  is  the  simplest,  and  that  is  to  provide  a readable  catalog 
listing.  The  only  required  parameter  is  the  path,  which  must  be  included  completely,  with  no 
substitutions  by  PD’s.  Using  the  earlier  example,  we  have 

/CATMAN  USERCAT/Dmm/Bmm/USERCl  l.FOSYS  = YES], 

This  would  list  all  of  a users  files  ( with  certain  restrictions  which  are  found  in  the  R.C.C.  com- 
puter note  #160).  The  optional  parameter,  POSYS  = YES,  is  used  if  one  wants  to  obtain  the 
original  catalog  listing.  Doing  this  once  and  comparing  the  two  print-outs  is  most  instructive. 

APPENDIX  II.  - VECTOR  PARAMETER  FILES 

A vector  is  a single  instruction  which  is  designed  to  perform  one  operation  on  a large 

mass  of  data.  There  are  two  advantages  to  using  vector  instructions  for  data  whenever  possible. 

The  first  is  that  less  time  is  spent  by  the  hardware  in  decoding  instructions,  since  it  only  has  to 

be  done  once  for  all  of  the  data,  whereas  scalar  code  requires  instruction  interpretation  of  each 

piece  of  data.  Since  there  is  some  overhead  associated  with  loading  a vector  parameter  file 

(VPF),  vectors  of  length  two  are  not  more  efficient  than  equivalent  scaler  code.  The  breakeven 

point  turns  out  to  be  for  data  structures  of  length  five  of  longer  The  second  advantage  is  that 
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entire  DO-LOOPS  can  be  contained  on  one  instruction,  and  since  the  hardware  can  anticipate 


where  the  next  data  will  be  coming  from,  it  can  proceed  to  fetch  it  before  the  central  procesor 
is  ready.  With  scaler  instructions,  the  memory  buffer  unit  must  await  instruction  decoding 
before  it  goes  to  fetch  the  data.  Thus  there  is  a two-fold  loss  in  time.  In  general,  vector 
instructions  are  designed  to  make  vector  and  matrix  arithmetic  look  like  the  straightforward 
operation  that  it  is  supposed  to  be. 

In  order  to  use  a vector,  the  VPF  must  be  loaded  into  V0-V7,  the  eight  vector  registers, 
and  the  operation  started.  With  the  two  arithmetic  units  available  on  ASC(#7),  two  vector 
instructions  can  be  executing  together. 

A vector  parameter  file  consists  of  eight  words  and  it  is  stored  in  a program’s  READ 

ONLY  or  READ/EXECUTE  area,  depending  on  the  compiler  which  is  used.  When  a vector  is 

to  be  executed,  the  VPF  is  loaded  and  the  command  excuted  using  the  instructions 

L 5,  (nnn,  B3) 

VECTX 

or 

VECTL  (nnn,  B3) 

where  nnn  represents  the  offset  in  the  READ  ONLY  area. 

The  form  of  a vector  parameter  file  (VPF!  is  shown  in  Table  (111).  This  is  the  form 
which  appears  in  the  source  listing  when  MFTN  is  used,  or  the  object  listing  wh  t FTN  is  used 
The  purpose  in  providing  this  table  is  for  decoding  a VPF  when  debugging  Users  might  also 
want  such  a table  when  optimizing  a program.  An  example  of  a VPF  found  in  a source  listing 
is  shown  in  Table  IV. 

More  information  on  the  vector  parameter  files  can  be  found  in  the  "Programmers'  Guide 
to  the  Central  Processor",  whose  number  is  (#930039). 
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TABLE  1 


LABEL 

OPERATION 

OPERANDS 

/(SYMBOL) 

MFTN 

(HELP)  - THIS  IS  THE  DOCUMENT  LIST  OPTION 

1,  IN  - ACCESS  NAME  (SYS  FIN)) 
i.OBJ  - ACCESS  NAME  (SYS.OMOD)l 
l.FTNOPT  - COMPILF.ROPTIONS  (K.M.U.V.D.Y.O)] 
l.FTNTIME  - CPTIME  (30000)) 

(.FADDMEN  - ADDMFN  <7K>) 

(.SPACE  - SPACE1 

1.VSPACE  - VSPACEl 

[.OBJ FILE  - MOD  or  NEW(MOD)) 

(.OBJSIZE  - BAND  ALLOCATION  ( 1/20/1  >1 
l.LISTSIZE  - BAND  ALLOCATION  (1/40/1)] 

I.LISTFILE  - MOD  OR  NEW 

- (MOD)  FOR  BATCH  AND 

- (NEW)  FOR  KEYBOARD  USERS  ) 

I.NPIPES  - INTEGER  (2)  ] 

(.COMPILER  - NXMMMM  OR  FXMMMM  (NX0527)  ) 
(.FTVERS  - COMPILER  TYPE  - NX  OR  FX  (NX)  1 
I.VPF  - YES  OR  NO(YES)  ] 

I.MFTNSEC  - TIME  IN  SECONDS  (15)  1 

I.SAVE  - YES  OR  NO(NO)) 

[.LONGL1ST  - OB’ECT  LISTING  DISPOSITION 
- REL,  YES.  NO  (RED) 

TABLE  II 


LABEL 

["OPERATION 

OPERANDS 

/[SYMBOL) 

MLNK 

(DOCUMENT  - YES  OR  NO(NO)] 

(.CONTROL  - CONTROL  CARDS  (SYS  LEIN)] 

(.LIST  - OUTPUT  FILE  (SYS  PRT)] 

I.OBJ  - INPUT  OBJECT  FILE  (SYS  OMOD)l 
(.LOAD  - OUTPUT  LOAD  MODULE  (SYS  LMODI) 

I.LNKOPT  - OP  OPTIONS  (M.A.X.I  .Q.SH 
(.START  - STARTING  ADDRESS  - ENTRY  POINTl 
(.NAME  - NAME  OF  LOAD  MODULE(GO)] 
l.LNKTIME  - CPTIME  FOR  LINK  (30000)) 

(.LADDMEN  - ADDMEM  <30K)1 

(.MEMLOAD  - MEMBER  NAME  OF  LOAD  MODULE) 

{.LOADLIB  - ACCESS  NAME  OF  A PDS  FILE) 

[.EOJ  - LABEL) 

l.LSPACE  - INTEGER  WORDS  0) 

I.LISTFILE  - NEW  OR  MOD  (NEW!) 

(.OLIBPATH  - OBJ  LIBRARY  FILE  (SYSMOPL)l 

I.OLIBVERS  - OBJ  LIBRARY  VERSION  (+0)1 

I.SYSIN  - YES  OR  NO(NO>] 

(.TABLDUMP  - YES  OR  NO) 
l.RTP  - RUN  TIME  PARAMETERS) 

I.MLNKSEC  - MLNK  RUN  TIME  (10)) 

I.LISTOPT  - LIST  OPTIONS  FOR  MLNK  - C.M.R.E  or  U(C)) 
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r ABLE  III 


ADDRESS 

CSN 


VRO 

OPR 

VRI 

VCTRA 

VR2 

VCTRA 

VR3 

VCTRA 

VR4 

DATAH 

VRS 

DATAH 

vre 

DATAH 

VR7 

DATAH 

OPTIONS.  IALCT.  SV.  LEM 
ADDRESS  OF  FIRST  ARGUEMF.NT  (SSA) 

ADDRESS  OF  THE  SECOND  ARGUMENT  (SSBl 
ADDRESS  OF  THE  THIRD  ARGUMENT  (SSCI 
INNER  LOOP  INCREMENT  FOR  ARG  1.2 

INNER  LOOP  INCREMENT  FOR  ARG 3 AND  INNER  LOOP  COUNT 
OUTER  LOOP  INCREMENT  FOR  ARG  1.2 

OUTER  LOOP  INCREMENT  FOR  ARG  3 AND  OUTER  I OOP  COUNT 


ADDRESS  - OFFSET  RELATIVE  TO  THE  READ-ONLY"  AREA 
CSN  - COMPI1  ER  STATI  MI  NT  NUMBER 

VRO  - VR7  - VECTOR  REGISTER  0 THRU  7 (FOR  A TOTAL  OF  EIGHT) 

VC TR  A - VECTOR  ADDRESS 

DATAH  - DATA  (TO  BE  GIVEN  IN  HALFWORDS) 


VRO  OPR  - OPER  ATION  (E  Ci  VOR) 

ALCT  - COMPARISON  M ASK 

SV  - SINGLE  VALUED  VECTOR  SWITCH  (SEE  PAGE  9 of  #931 
LEN  - LENGTH  OF  THE  SELF  LOOP 
VRI  ADDRESS  OF  VECTOR  A’  IN  THE  FORM  INNN.X  REGISTER) 

V R2  ADDRESS  OF  \ 1 ( TOR  H IN  THE  FORM  (NNN.X  REGISTER) 

VRI  ADDRESS  Ol  VEC  TOR  C IN  THE  FORM  (NNN.X  REGISTER) 

VR4  INNER  LOOP  INCREMENT  (EACH  IS  A HALFWORD) 

VRS 

VRE  OUTI  R I OOP  INCRI  MI  NT  (EACH  IS  A HALFWORD) 

VR7 


TABLE  IV 


I LOCATION 

HEX  VALUE 

MNEMONIC 

000020 

6E0D000A 

VMF 

0.10.13 

00000618 

VCTRA 

Y 

6 

00000228 

VCTRA 

Z 

00000230 

VCTRA 

X 

00010000 

DATAH 

1.0 

000 1 0064 

DATAH 

1.100 

00000000 

DATAH 

0,0 

which  came 

00000001 

from  the  statement 
DO  1 J - 1.100 
DO  1 1 - 1.10 

DATAH 

0.1 

0006  1 

X(I.J)  - Z • Y(I.J) 
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